先說整個系列的小結

Opentelemetry

透過這個系列的demo，我們大致了解到 Opentelemetry 這個協議與其工具，它定義好了 Trace、Metric data、Log 的 data model 基本會長什麼樣子，而且其開源社區也提供了許多不同的庫來應用在不同採集對象、採集階段、甚至不同開發語言。

這樣一來，給了開發者極大的彈性，可以在基於 Opentelemetry 採集到的數據上做二次處理，來賦能自家的監控產品。

Sentry

Sentry 就是一個很好的例子，除了原本對錯誤異常的捕獲外，在 tracing 的這個功能上，也使用了 Opentelemetry 的一些開源庫（各種 instrumentation），監控應用內部的各種異步操作，例如資料庫查詢、HTTP 請求的狀態。因此能夠在錯誤發生時提供完整的請求路徑，也可以進一步分析性能瓶頸。

Grafana

而 Grafana 就更不用說了，直接在 Opentelemetry 上玩出了花。在 Opentelemetry 的支持下，Grafana 可以從多種源頭（如 Prometheus、Jaeger 等）收集遙測數據，並提供靈活的儀表板（dashboard）讓開發者根據需要進行定製化的數據展示。

同時 Grafana Lab 也自己開發了採集server，也是透過 Opentelemetry 採集的數據做處理，如處理 log data 的 Loki、處理trace data的 Tempo。

Vercel

NextJS 的公司 Vercel 也有自己的採集工具@vercel/otel，它是對 @opentelemetry/api 等庫做二次封裝，其用意是在降低了開發者在 NextJS 專案中整合 Opentelemetry 的門檻。通過簡單的配置，開發者直接將 tracing data 導出到其他第三方監控平台，例如 New Relic 和 Datadog，讓開發者不必擔心數據格式和傳輸協議的問題，專注於應用開發。這也算是 Vercel 吸引開發者使用並付費的地方---整合CICD、雲管理和應用監控。

小結

Opentelemetry 作為一個開放標準，讓像 Sentry、Grafana 和 Vercel 等等平台，可以在其基礎上進行擴展，提供更多元化的監控選項。這些工具各自針對不同的監控需求進行了深度整合，但都依賴於 Opentelemetry 的強大能力。這種靈活的架構不僅能夠幫助開發者精確定位問題，還可以輕鬆擴展到不同的應用場景中，實現完整的觀測解決方案。

完賽心得

在最初準備這個系列的時候，儘管我很快決定了主題，但大綱卻一直難產，主要原因是看到在 Opentelemetry、Observability、Grafana 等主題中，已經有了許多強者前輩在鐵人賽的分享，前人之述備矣，我這樣一個沒有相關實戰經驗的人，再淺顯地重述一遍似乎意義不大，甚至顯得多餘。

因此，我最終選擇了一個對我來說更為實際和有趣的切入方式——通過簡單的 demo 演示來介紹技術，然後再深入查看相關的原始碼，探討這些監控指標是如何被捕獲的，並進一步嘗試手寫實現一些核心功能。基本上這個系列就是靠這個三件套：demo、分析原理、手寫邏輯，在入職新工作前20天拼命累積草稿，在自學的同時偷偷破關這鐵人賽。

雖然想努力展現在這個方面的理解與學習心得，但無奈累積真的不夠多，很多細節沒辦法展開來好好說明。在之後的工作中，希望有機會可以應用並更深入理解，然後在這系列文中補上更有見地的觀點。

同時，也希望讀到這邊的讀者能夠在這個系列文中有某種程度的收穫；如果沒有，我會再努力的。

See you at the top!

ChangeLog

• 20241013--補充內文
• 20241002--初稿大綱